![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/spacer.gif) |
Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT
Peter Grun, Chulho Shin – ARM,
USA Chris Baxter, Christopher Lennard – ARM Ltd,
UK Mark Noll – Synopsys, USA Gabor Madl -
University of California, Irvine, USA
Abstract:
System design flows are
traditionally multi-vendor. The adoption of electronic system-level
(ESL) design and highly configurable IP is increasing the dis-aggregation
of the supply-chain. This demands a new kind of information exchange
between tools and IP: SoC design configuration meta-data.
Design-flow integration is helped by utilizing meta-data exchange in the
design-language neutral SPIRIT XML format. In this paper, we will
show how this standard is helping to close the gulf between ESL design
exploration environments and the SoC implementation flows. We have
proven the use of system configuration and integration data exchange on
production IP and tools. We show a SPIRIT-enabled flow from the ARM
RealView SoC Designer SystemC tool to coreAssembler, the Synopsys SoC
assembly, implementation, and verification environment, using an
ARM1176JZ-STM processor subsystem design example
INTRODUCTION
Customer demand has
made support for integrated multi-vendor design flows a necessity for EDA
and design IP providers. System designs and configurable IP must be
exchanged rapidly and consistently between the different stages of the
design process, the teams that manage those stages, and the specific tools
that support them [1][2].
An example of the issues faced by
systems-design houses is given in Figure 1. This shows a possible
multi-vendor and design-language co-ordination of tools and IP in a
typical SoC design flow. It shows the types of design views that
must be kept consistent. It is clear that exchange of design
configuration between individual tools cannot be on a case-by-case
basis. Maintaining the consistency of SoC designs today requires a
single, language-and-vendor neutral way to express IP and the
configuration of a SoC design as it progresses through the refinement
process [3].
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit1.gif)
Figure 1:
Configuration data exchange needed in example multi-vendor
flow
In this paper, we introduce the reader to the SPIRIT
standard [4] and its usage. The SPIRIT standard provides an XML
schema [5][6] and set of semantic interpretation rules. A design
component can be described with SPIRIT meta-data enabling it to be
automatically imported, assembled, and configured consistently through the
various stages of a SPIRIT-compatible multi-vendor flow. The SPIRIT
standard also defines the notion of a generator, which is a stand-alone
process which can run within a SPIRIT-compatible design environment.
Generators enable the integration of point-tools for manipulation of
SPIRIT components within a design environment.
We provide
evidence of production use of the standard on a configurable AXI
system-design using the ARM 1176JZ-S processor and tools from at least two
vendors currently supporting SPIRIT.
A SUMMARY OF THE SPIRIT
STANDARD
The development of the SPIRIT standard has been
split into two phases, the first (SPIRIT 1.x) is to address RTL design and
verification flow integration, and the second (SPIRIT 2.x) is to address
electronic system-level design. The first versions of the SPIRIT standard
have already been proven against production RTL design exchange.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit2.gif) Figure 2: SPIRIT
usage in a SoC Design Environment
The typical usage model
for SPIRIT within a design-environment is shown in Figure 2. The
user of such a design environment will be able to gather SPIRIT component
descriptions (files) together into a library, along with SPIRIT-compatible
definitions for any bus interfaces referenced within the components. The
key contents of a SPIRIT 1.x component definition include: top-level I/O,
bus interfaces, definition of memory map, the various views of the IP,
including the files required to ‘see’ a particular view, and
implementation constraints which must be met in order for the IP to
properly function within the subsystem. SPIRIT bus definitions
define a standard connection protocol and the bus interfaces within a
SPIRIT component description are essentially an instantiation of the bus
definition. For example, there is a standard bus definition for an APB
slave interface. A simple slave such as a watch-dog timer might then
contain a bus interface, instantiating the APB slave bus definition. This
provides all of the information necessary to attach the peripheral to the
APB bus fabric.
A design environment (integrated tool flow) can
instantiate and connect SPIRIT components to form a design, which is
itself represented as a SPIRIT design file. A SPIRIT design file describes
which components are instantiated, how their bus interfaces are connected,
component configuration details, and any ad-hoc, or non-interface based
connections between components. It is expected that systems integrators
will want to augment the functionality of their design-environment with
point-tool functionality. These are tools called to implement
specific design, or design verification, tasks. Therefore, SPIRIT defines
the concept of generators, which can be plugged into any SPIRIT compatible
design environment to provide custom features. In the 1.1 schema,
generators communicate with the design environment using a loose generator
interface (LGI). This is a file based API which provides access to the
component and design files comprising the current design, and which
supports updates (primarily component replacement and connection changes)
through an LGI changes file. This is processed by the design
environment when the generator has finished running. The SPIRIT 1.2 schema
will provide a much finer grained interface, known as the tight generator
interface (TGI). This language neutral interface utilizes SOAP [7] for
communication between generator and design environment. Generators can use
the TGI to get any information represented by the SPIRIT schema files, and
can set the value of any element which has been defined to be user
resolvable, as indicated by the existence of the ‘spirit:resolve’
attribute set to the value “user”. SPIRIT generators can be invoked
individually or they can be linked together using a SPIRIT generator
chain. This is another SPIRIT file type, used to describe sequences
of generators which should be run as a unit.
There are two
additional types of SPIRIT files that can be utilized in a SPIRIT design
environment. The first is a platform meta-data file (PMD) which describes
transformations that should be made to a component when it is instantiated
in a design environment and when certain conditions are met. For example,
when instantiating an APB slave, a PMD file might be used to specify
certain configuration values if another dependent APB slave is already
instantiated in the subsystem. The second additional file type is new to
the SPIRIT 1.2 schema. The design configuration file is used to store
information that is not component or design specific. This includes the
currently selected view of each component, and configuration values for
generator chains and PMD files.
Version 2.0 of the SPIRIT standard
addresses the Electronic System Level (ESL) and transactional verification
IP. The SPIRIT v2.0 standard will enhance interchange of models described
at different level of abstraction by providing a way for IP providers to
describe the interfaces used by their models, and identifying transactors
that are needed to integrate those models into different simulation
environments. SPIRIT v2.0 supports the concept of abstraction levels
through component ‘views’, and bus interface ‘abstractions’. Given
this information, multi-level system simulations can be automatically
built from a topological system description and configuration in SPIRIT.
In Figure 3 we show a simple example of a multi-abstraction
design, where a SPIRIT v2.0 design can be configured using the SPIRIT
configuration files to target different levels of abstractions. The
component “views” are used to represent the different abstraction levels
of the component. The connectivity of the system must be kept
consistent as different IP views are switched in and out.
Maintaining that connectivity will often imply the insertion (or removal)
of transactors that translate interface activity between abstraction
levels. This implication can be deduced from the SPIRIT connectivity
requirements.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit3.gif) Figure 3: Hierarchy
of views and busInterfaces in SPIRIT 2.0
Beyond simple
transactor insertion, different levels of abstraction of a component
usually exhibit differences in the interfaces supported. For example, the
RTL interface in general will be more refined, containing more details
then the TLM interface. This requires that consistent concepts of
connectivity be transported between system views, while other detail can
be added / removed specific to the system view. This is
supported in SPIRIT v2.0 by a set of interface and abstraction level
constructs including the “bus interface”, “bus abstraction”, “abstraction
definition” and “bus definition” constructs. In Figure 4
we illustrate this in more detail with an example component (a
microprocessor) that contains 2 views: the TLM view and the RTL
view. In the ESL view of the system the microprocessor is
connected to a transaction-level system-bus. At the RT level, there
is connectivity to both system and interrupt buses. Through the
separation of abstraction definitions and bus definitions, SPIRIT enables
the system interconnect constraints to be transported between these
different views of the system.
A bus IP is defined by a “bus
definition”, describing the list of signals for wire to wire connections.
The “abstraction definitions” represent the abstraction levels of that bus
IP, and reference the “bus definition” they belong to. Each component may
contain one or more bus interfaces. Each such interface allows connecting
the component to a bus. The bus interfaces will contain “bus abstractions”
that reference the “abstraction definitions” they correspond to. In the
example from Figure 4, the System and Interrupts bus definitions are
referenced by their respective RTL and TLM abstraction definitions. Both
the RTL and TLM views of the component reference the Memory bus interface,
while the RTL view references the Interrupts bus interface.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit4.gif) Figure 4: Support for
multiple levels of abstraction in SPIRIT 2.0
By supporting
descriptions at different levels of abstractions to have different
interface footprints, structural consistency between different simulation
levels is formalized. This allows users to move rapidly between
views of the design trading off different goals such as simulation speed
and accuracy seamlessly. The complete design flow is driven from a
unique topological SPIRIT design file.
MAPPING A SystemC DESIGN TO
SPIRIT
All SoC design tools maintain an internal database to
act as a repository for the system model connectivity, register and
bus-interface configuration, and system memory maps. For a
SPIRIT-compatible design environment, this database is related to a SPIRIT
description of the IP and system. An example is shown in Figure 5, where
the internal database is identified as (.mxp). In general, such a tool
will have a wizard for manual edits to the SPIRIT-specific view of the
design, as well as supporting automatic import for existing SPIRIT files.
In this way, regardless of an internal proprietary data-base format, the
import of a design IP import will capture and create the
multi-vendor SPIRIT description for an IP.
Changing
connections, duplicating, removing or configuring components in a system
design will automatically update the design tool’s internal
data-base. As part of the SPIRIT standard, it is mandatory that any
SPIRIT-compatible design-environment also reflect these changes into the
SPIRIT description of the full design. Hence, once an optimal design
is determined using fast models at the ESL level, the language-neutral
description of the system interconnect and configuration can be exported
immediately to an RTL tool.
Mapping of a SPIRIT design to the
SystemC interface constructs is enabled through simple equivalence
relations between the SPIRIT and internal tool data structures. In the
example of Figure 5, the ESL design environment works with two different
kinds of internal configuration files. One is a library configuration file
(.conf) and the other is a design file (.mxp). A library configuration
file contains IP library-specific information such as library types and
paths. A design configuration file contains information such as IP
instance names, connectivity and instance-specific
parameters.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit5.gif) Figure 5: SPIRIT
usage in an ESL design tool
To enable complete import and
export between design environments, SPIRIT requires the addition of
explicit data-handling detail which otherwise may be implicit in a single
tool. The library and design configuration files need to be
annotated to express design IP properties (SPIRIT library module name and
path), ports (SPIRIT port name, type and corresponding SPIRIT bus
interface VLNV), and a TLM-to-SPIRIT port mapping table reusable across
designs.
For TLM support, the internal design configuration
file (.mxp) must be annotated to support SPIRIT channel information.
Channels are IP connection elements with specific interfacing rules that
enable netlisting between masters and slaves for non-symmetric protocols
(e.g., AHB master and slave interfaces are non-symmetric). Channels are
handled as pseudo-elements in the ESL design tool as they are not
necessary for ESL connections. This is due to the fact that there is
no concept of symmetry in signal interfaces at the TLM level.
USING SPIRIT TO ENTER THE
HARDWARE IMPLEMENTATION FLOW
To move from an ESL tool to a
hardware implementation tool, the SoC design must cross a design
environment and design language boundary. In this case, we are
examining the flow from a SystemC ESL design tool exporting a SPIRIT
representation (components and designs) of the SoC design to a design
environment supporting a path through to implementation. To enter
this hardware implementation process, it is most important that the script
generation process is directly enabled. Automation of this process
allows the user of the design environment to leverage the expertise of the
script generation authors without requiring them to become an expert in
the implementation tools themselves. A script generator takes into account
the specific aspects of the implementation flow being used, including
specific tools and tool versions, the specific target technology
(including details about cells available in the library), the subsystem
design constraints, and information about how each IP block is ‘intended’
to be implemented. We describe the latter two aspects of this
flow.
Subsystem design constraints include input/output timing
requirements, DRC requirements, external drive/load characteristics, clock
definitions, and timing exceptions such as false and multi-cycle paths.
This type of synthesis information is well standardized in the industry,
and common to multiple flows. As such, this information can be
provided directly in the SPIRIT component file. A set of example
constraints specified using the SPIRIT constraint schema is shown in
Figure 6 below for a typical input signal.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit6.gif) Figure 6: Example
design constraints for an input signal
Constraints are
specified in a technology independent manner whenever possible. In the
constraint example, both the input delay constraint and the drive
constraint are specified without reference to a particular implementation
technology. This greatly enhances the portability of the constraints as
the IP can be targeted to different technologies without any updates to
the SPIRIT meta-data.
Synthesis ‘intent’ is the final critical
input to the script generation process. This is (mostly) tool
independent information about how an IP block is intended to be
implemented. For example, an IP developer might indicate that a particular
block contains many arithmetic components. The script generator can
then create a script for that IP block which focuses more on arithmetic
optimization than it would in the default case. This ‘intent’ is
what drives the script generator when creating a script to compile a
specific IP block. There are a number of different pieces of information
which can be specified for synthesis intent, including: optimization
focus, design characteristics, hierarchy preservation, blocks, to compile,
customizations, DFT intent, and physical intent. While a common concept,
the expression of intent is often vendor specific. SPIRIT enables
the capture of the specific parts of this implementation flow through use
of vendor-supplied extensions.
The synthesis script
generator must be able to generate scripts for the targeted implementation
tools which provide excellent quality-of-results, without requiring any
manual modifications. Otherwise the value of the automated process
is not high enough to justify the loss of control over the implementation
flow. Manual modifications should not be required, but controlled
customization must be allowed to account for special implementation
requirements which inevitably occur when implementing a large subsystem. A
common customization example is the need to prevent the use of specific
cells from the target technology library.
There are two primary
steps required to generate the implementation scripts. First, conflicts
between implementation constraints must be resolved. An assembled
subsystem may have a common input signal connected to an IP block which
has a ‘40% of the cycle time’ input delay constraint, and to an IP block
which has a ‘60% of the cycle time’ input delay constraint. The most
practical solution is to keep the more pessimistic constraint (tighter
delay constraint, larger load constraint, weaker drive constraint, etc.).
Second, the script generator must leverage its knowledge of how to drive
the selected implementation tools, and information gathered from analysis
of the target technology libraries, to transform the synthesis intent into
the actual generated scripts used to drive the implementation tools. The
process described above is highlighted in Figure 7.
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/20060116_spirit7.gif) Figure 7: SPIRIT
enabled HW implementation flow
A SPIRIT DESIGN FLOW IN PRACTICE
We have developed an integrated system-design flow using a
SystemC representation for system validation and performance analysis, and
an RTL representation used as the entry point into the implementation
flow. The ARM SystemC design environment RealView SoC Designer with
MaxSim® technology [8], and the Synopsys coreAssembler [9] tools have been
used to validate this integration through SPIRIT meta-data exchange.
The design validation was performed on an ARM1176JZ-S processor core
subsystem.
The example ARM1176JZ-S processor core subsystem
supports the basic components required to enable embedded software to be
executed by the processor core (i.e. RAM, ROM, a timer and interrupt
controller). This is connected using AMBA AXI bus fabric
infra-structure components. All of these components have RTL views,
and corresponding SystemC models within the ARM RealView SoC Designer ESL
tool, enabling fast cycle-based simulation. The transaction level
interface used is the ARM RealView ESL simulation API, a cycle-based
transactional interface. The experiments were performed using
SPIRIT v1.1. ARM initially captured SPIRIT meta-data for the
core and subsystem components, including:
- The RTL I/O signals.
- Any design files are used to describe the functionality of the
component e.g. Verilog RTL source files. Multiple sets of design files
can be defined to support different views of the components
implementation, e.g. Verilog and VHDL RTL views.
- The interfaces supported by the component at an abstract level (e.g.
a AXI slave port) and the I/O signals used to implement the interface.
- For simple peripherals with standard interfaces, it takes less than
half a day to capture and validate SPIRIT descriptions. For cores
with multiple complex bus interfaces (e.g., co-processor, interrupt bus,
etc.), the engineering time to capture a SPIRIT description depends on
the degree of re-use of validated bus definitions. After
completion, the SPIRIT component definitions were imported into SoC
Designer and the coreAssembler tools.
In the SoC Designer
tool, a SPIRIT SoC design definition is relatively straight forward to
create as it is only required to define the components instantiated in the
design, the parameter values associated with the instantiate components
and the interconnect between the interfaces provided by the
components. As there is a direct alignment between the SPIRIT and
SystemC component interface definitions, the SystemC representation of the
system is a direct mapping of the design definition held within the SPIRIT
design definition.
As the present SPIRIT v1.1 definition of
the SPIRIT schema only provides explicit support for RTL interfaces, the
definition of component interfaces at the SystemC level is performed by
overloading the SPIRIT interface definitions within the component
meta-data. This implies that the names defined for the SPIRIT interface
definitions and the SystemC interfaces must be identical. This support of
direct port-to-pin mapping enables the SoC netlist to be directly
translated from SystemC model interconnect to RTL component
connectivity.
After completion of the system level simulation, the
subsystem was exported in the SPIRIT format and imported into the Synopsys
coreAssembler tool to begin the path to implementation. The SPIRIT
export/import process enables an automatic transfer of the components and
their connectivity from the system level design environment into
coreAssembler. In this particular case, the front-end portion of the
coreAssembler flow (IP assembly) has been completed in RealView SoC
Designer so the subsystem designer can move directly to the implementation
flow. The first step in this flow is to choose a target technology
library. The library is analyzed in coreAssembler in order to choose the
optimal cell set for synthesis and to allow the tool to convert technology
independent constraints into constraints specific to the chosen
technology. The next step in the flow is to override component level
constraints as appropriate for the context in which the subsystem will be
used. The subsystem designer then chooses an implementation strategy
targeting one or more of the following tools: Design Compiler, Physical
Compiler, DFT Compiler, DC-FPGA Compiler, TetraMax. Synthesis scripts and
a top-level makefile are then generated automatically, taking the tool
version, target technology, and optimization constraints into account. The
makefile enables both parallel implementation of components in the
subsystem, and reproducibility outside of the coreAssembler environment.
After the synthesis process completes, generated reports are automatically
converted to HTML and summarized to enable efficient review of the results
and to help pinpoint problems if constraint violations exist. The end
result is an automated process which provides excellent quality-of-results
[10] without manual intervention across all of the key Synopsys
implementation tools.
CONCLUSIONS
The SPIRIT
standard is already being proven to resolve some difficult integration
issues with multi-vendor / multi-language flows. We have shown flow
integration from SystemC to Verilog, across two tools from two
vendors. This was shown on production tools featuring SPIRIT
support.
There is an excellent future for the adoption of the
SPIRIT standard. It is immediately useful for RTL and structural
SystemC IP exchange, and over the next year we will see meta-data exchange
across multiple levels of design abstraction. Given the increasing
complex set of design views that must be kept consistent from architecture
inception to final silicon, the role of SPIRIT will become increasingly
critical for efficient design-chain integration.
REFERENCES
[1] FPGA
Journal: “Samsung's ViP Design Methodology Reduces SoC Design Time Up to
40 Percent” http://www.us.design-reuse.com/exit?url=http://www.fpgajournal.com,
September 2004
[2] Alberto Sangiovanni-Vincentelli, Grant Martin,
“A Vision for Embedded Systems: Platform-Based Design and Software
Methodology”. IEEE Design and Test of Computers, Volume 18, Number
6, November-December, 2001, pp. 23-33.
[3] Christopher K. Lennard,
Eric Granata, “The Meta-Methods: Managing design risk during
IP selection and integration”. European IP 99 Conference, November
1999
[4] SPIRIT Consortium, “SPIRIT 1.1 Specification”, http://www.us.design-reuse.com/exit?url=http://www.spiritconsortium.org,
June 2005
[5] World Wide Web Consortium, “Extensible Markup
Language (XML) 1.0” Third Edition, 2004
[6] World Wide Web
Consortium, “XML Schema Part 1: Structures”, Second Edition; “XML
Schema Part 2: Datatypes” Second Edition, 2004
[7] SOAP
Specifications: http://www.us.design-reuse.com/exit?url=http://www.w3.org/TR/soap
[8]
ARM RealView ESL Tools: http://www.us.design-reuse.com/exit?url=http://www.arm.com/products/DevTools
[9] Synopsys IP Reuse Tools: http://www.us.design-reuse.com/exit?url=http://www.synopsys.com/products/designware/ipreuse_tools.html
[10]
Gerard Humeau, Xavier Robert, Jehan-Philippe Barbiero, Julien Guillemain,
Gauthier Barret, “Enabling the Delivery of Super10 Nexus
On-Chip-Emulator as Soft IP”, SNUG Europe 2003
list: -1137502347.76 seconds detail:
0.000515937805176 seconds prov: 0.00070595741272 seconds end_new
|
![](Integrating a Multi-Vendor ESL-to-Silicon Design Flow Using SPIRIT_files/spacer.gif) |